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Abstract 

Many millions of users routinely use their Google accounts to log 
in to relying party (RP) websites supporting the Google OpenID Con¬ 
nect service. OpenID Connect, a newly standardised single-sign-on 
protocol, builds an identity layer on top of the OAuth 2.0 protocol, 
which has itself been widely adopted to support identity management 
services. It adds identity management functionality to the OAuth 2.0 
system and allows an RP to obtain assurances regarding the authen¬ 
ticity of an end user. A number of authors have analysed the security 
of the OAuth 2.0 protocol, but whether OpenID Connect is secure in 
practice remains an open question. We report on a large-scale prac¬ 
tical study of Google’s implementation of OpenID Connect, involving 
forensic examination of 103 RP websites which support its use for sign- 
in. Our study reveals serious vulnerabilities of a number of types, all 
of which allow an attacker to log in to an RP website as a victim user. 
Further examination suggests that these vulnerabilities are caused by 
a combination of Google’s design of its OpenID Connect service and 
RP developers making design decisions which sacrifice security for sim¬ 
plicity of implementation. We also give practical recommendations for 
both RPs and OPs to help improve the security of real world OpenID 
Connect systems. 


1 Introduction 

In order to help alleviate the damage caused by identity-oriented attacks 
and simplify the management of identities, a range of identity management 
systems, such as OAuth 2.0, Shibboleth, CardSpace, OpenID, have been 
put forward [20l ;25, 36]. As a replacement for the well-established OpenID 
pj] scheme, OpenID Connect 1.0 [37] builds an identity layer on top of 
the OAuth 2.0 framework [25] • The OAuth 2.0 framework enables an RP 
to obtain profile information about the end user, but does not provide any 
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means for the RP to obtain information about the authentication of the end 
user. In OpenID Connect, in addition to obtaining profile information about 
the end-user, RPs can obtain assurances about the end user’s identity from 
an OpenID Provider (OP), which itself authenticates the user. 

OpenID Connect involves interactions between four core parties: 

1. the End User (U), who attempts to access on-line services protected 
by the RP; 

2. the User Agent (UA), typically a web browser, that is employed by 
an end user to transmit requests to, and receive responses from, web 
servers; 

3. the OpenID Provider (OP), e.g. Google, which provides methods to 
authenticate an end user and generates assertions regarding the au¬ 
thentication event and the attributes of the end user; 

4. the Relying Party (RP), e.g. Wikihow, which provides protected on¬ 
line services and consumes the identity assertion generated by the IdP 
in order to decide whether or not to grant access to the end user. 

In summary, the end user employs a user agent to access resources pro¬ 
vided and protected by the RP, which relies on the OP to provide authentic 
information about the user. 

Even though OpenID Connect was only finalised at the start of 2014, 
there are already more than half a billion OpenID Connect-based user ac¬ 
counts provided by Google [9], PayPal jTj and Microsoft [3]. This large 
user base has led very large numbers of RPs to integrate their services with 
OpenID Connect. 

The security of OAuth 2.0, the foundation for OpenID Connect, has 
been analysed using formal methods [32 j 33ES0- Research focusing on im¬ 
plementations of OAuth 2.0 has also been conducted [221 SB TT H7 ], 
However, as a newly standardised protocol, it is not yet clear whether prac¬ 
tical implementations of OpenID Connect properly follow the specification 
m • Given the large scale use of the Google service, it is important to un¬ 
derstand how secure deployments of OpenID Connect really are. In order to 
help answer the question, the operation of all one thousand sites from the 
GTMetrix Top 1000 Sites dJ providing services in English was examined. 
Of these sites, 103 were found to support the use of the Google’s OpenID 
Connect service, at the time of our survey (early 2015). All 103 of these 
websites were then further examined for potential vulnerabilities, with the 
results as reported in this paper. In our study, all the RPs and the Google 
OP site were treated as black boxes, and the HTTP messages transmitted 
between the RP and OP via the browser were carefully analysed to identify 
possible vulnerabilities. For every identified vulnerability, we implemented 
and tested an exploit to evaluate the possible attack surface. 
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Our study reveals serious vulnerabilities of a number of types, which 
either allow an attacker to log in to the RP website as the victim user or 
enable the compromise of potentially sensitive user information. Google 
has customised its implementation of OpenID Connect by combining SDKs, 
web APIs and sample code, and as a result the OpenID Connect specifica¬ 
tion only acts as a loose guideline to what RPs have actually implemented. 
Further examination suggests that the identified vulnerabilities are mainly 
caused by RP developers misunderstanding how to use the Google OpenID 
Connect service, and by making design decisions which sacrifice security for 
simplicity of implementation. Some of the attacks we have discovered use 
cross-site scripting (XSS) [34, 33, 05l (30] and cross site request forgeries 
(CSRFs) [13 [23J |29l [33l (46] . well-established and widely exploited attack 
techniques. 

OpenID Connect is being used to protect millions of user accounts, as 
well as sensitive user information stored at both RPs and the Google OP 
server. Moreover, as of April 20th 2015, Google shut down its OpenID 
2.0 [8] service; as a result a huge number of RPs have had to upgrade 
their Google sign-in service to use OpenID Connect. It is therefore vitally 
important that the issues we have identified are addressed urgently, and that 
Google considers issuing updated advice to all RPs using its service. In this 
connection we have notified all the RPs in whose OpenID Connect service 
we have identified serious vulnerabilities, as well as Google itself. 

The remainder of the paper is organised as follows. In Section 2 we 
give an overview of OpenID Connect. We describe our adversary model in 
section 3. Section 4 describes the experiments we performed to evaluate the 
security of Google’s implementation of OpenID Connect. Possible reasons 
for the identified vulnerabilities are discussed in section 5. In section 6 we 
give proposed mitigations for these vulnerabilities, we review related work 
in section 7, and section 8 concludes the paper. 

2 OpenID Connect 

2.1 Introduction 

OAuth 2.0 [25] enables an end user to grant an online service controlled 
access to his or her personal details (e.g. email address, birth date, pictures) 
held by a third party, without revealing his or her password for this third 
party. Without the help of a system like OAuth 2.0, relying parties (e.g. 
Wikihow) would need to ask the user to provide his or her password in order 
to access user information stored at a third party (e.g. Google), which is a 
less than ideal solution. 

As already noted, OpenID Connect 1.0 m is built as an identity layer 
on top of the OAuth 2.0 protocol. The functionality that it adds enables RPs 
to verify the identity of an end user by relying on an authentication process 
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performed by an OpenID Provider (OP), i.e. it adds identity management 
functionality to the OAuth 2.0 system. 

2.2 OpenID Connect Tokens 

In order to enable an RP to verify the identity of an end user, OpenID 
Connect adds a new type of token to OAuth 2.0, namely the id-token. This 
complements the access-token and code , which are already part of OAuth 
2.0. These three types of token are all issued by an OP, and have the 
following functions. 

• A code is an opaque value which is bound to an identifier and a URL of 
the RP. Its main purpose in OpenID Connect is as a means of giving 
an RP authorisation to retrieve tokens from the OP. In order to help 
minimise threats arising from its possible exposure, it has a limited 
validity period and is typically set to expire shortly after issue to the 

rp [25|. 

• An access-token contains credentials used to authorise access to pro¬ 
tected resources stored at a third party (e.g. the OP). Its value is an 
opaque string representing an authorization issued to the RP. It en¬ 
codes the right for the RP to access data held by a specified thrid 
party with a specific scope and duration, granted by the end user and 
enforced by the RP and the OP. 

• An id-token contains claims about the authentication of an end user 
by an OP together with any other claims requested by the RP. Claims 
that can be inserted into such a token include: the identity of the OP 
that issued it, the user’s unique identifier at this OP, the identity of 
the intended recipient, the time at which it was issued, and its expiry 
time. It takes the form of a JSON Web Token [28] and is digitally 
signed by the OP. 

Both an access-token [7J and an id-token US] can be verified by making 
a call to the web API of the issuing OP. 

2.3 Authentication Flows 

OpenID Connect builds on user agent HTTP redirections. We suppose that 
an end user wishes to access services protected by the RP, which consumes 
tokens generated by the OP. The RP generates an authorization request on 
behalf of the end user and sends it to the OP via the UA, which is typically 
a web browser. The OP provides ways to authenticate the end user, asks 
the end user to grant permission for the RP to access the user attributes, 
and generates an authorization response which includes tokens of two types: 
access-tokens and id-tokens , where the latter contain claims about a user 
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authentication event. After receiving an access-token , the RP can use it to 
access end user’s attributes using the API provided by the OP, and after 
receiving an id-token the RP is informed about the authentication of the 
user, as summarised in Fig. 12.11 



1: Authorization Request 

-► 



2: Authorization Grant 

-► 


3: Authorization Response 
■* - 


4: User Attributes Request 

-► 


5: User Attributes Response 



Figure 2.1: OpenID Connect Protocol Overview 


Google’s implementation of OpenID Connect [37] supports four types of 
authentication flow [9], i.e. ways in which the system can operate, namely 
Authorization Code Flow, Hybrid Server-side Flow (also knows as Hybrid 
Flow ) [TO], Client-side Flow (also known as Implicit Flow), and Pure Server- 
side Flow. However, as the Pure Server-side Flow is rarely used and Google 
states that this flow is not recommended, we only give detailed descriptions 
of the first three flows. 

The RP must register with the OP before it can use Google OpenID 
Connect. During registration, the OP gathers security-critical information 
about the RP, including the RP’s redirect URI or origin. The redirect URI 
is used in the Authorization Code Flow, and is the URI to which the user 
agent is redirected after step 5 (see step 5 of section 12.3.31) . The origin is 
used in the Hybrid Server-side Flow and Client-side Flow, and is a pointer 
to the domain name of the RP. The OP issues the RP with a unique identifier 
( client-id ) and a secret ( client-secret ) which it uses to authenticate the RP 
when using the Authorization Code Flow or Hybrid Server-side Flow. 
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2.3.1 Hybrid Server-side Flow 

Google’s OpenID Connect implementation uses postMessage [Q [5, 18 3 40) 
to enable cross domain communication between the RP and Google’s OP. 
Normally, scripts on different pages are only allowed to access each other 
if the web pages that caused them to execute are at locations sharing the 
same protocol, port number and host. The postMessage method lifts this 
restriction by providing a way to securely pass messages across domains. 
Further information on the operation of postMessage can be found, for 
example, in Son and Shmatikov m ■ In the Hybrid Server-side Flow and 
Client-side Flow, an RP Client is running on the UA and listening for the 
postMessage event. 

We now give a detailed description of the Hybrid Server-side Flow. 

1. U —^ UA —» RP: The user clicks the Google Sign-In button rendered on 
the RP website, and this causes the UA to send an HTTP or HTTPS 
request to the RP. 

2. RP —>• UA —>• OP: The RP generates an OpenID Connect authorization 
request and sends it to the OP via the UA. The authorization request 
includes client-id, an identifier the RP registered with the OP previ¬ 
ously; response-type=code token id-token which requests that a code, 
an access-token and an id-token be returned directly from Google; 
redirect-uri=postmessage, indicating that postMessage is being used; 
state, an opaque value used by the RP Client to maintain state between 
the request and the callback (step [5] below); origin, a URL without a 
path appended; and scope, the scope of the requested permission. 

3. OP —> UA: If the user has already been authenticated by the OP 
then this step and the next are skipped. If not, the OP returns a login 
form which is used to collect user authentication information (e.g. user 
account and password). 

4. U —>• UA —)• OP: The user completes the login form and grants per¬ 
mission for the RP to access the attributes stored by the OP. 

5. OP —>■ UA: After receiving the permission grant from the user, the 
OP generates an HTML document which contains the authorization 
response and sends it back to the UA. The authorization response 
contains the code, access-token and id-token generated by the OP; 
and state, the value sent in step [2j 

6. UA —> RP: The UA executes the JavaScript inside the HTML docu¬ 
ment it received in the previous step. The JavaScript sends the au¬ 
thorization response using postMessage to the RP Client which is 
running on the UA and listening for the postMessage event. After 
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the RP Client receives the authorization response it extracts the code 
and sends it back to the RP. 

7. RP OP: The RP produces an access-token request and sends it 
to the OP token endpoint directly (i.e. not via the UA). The request 
includes grant-type=authorization-code, indicating that the RP wants 
to use the code to retrieve an access-token from the OP; the code gen¬ 
erated in step El redirect-uri=postmessage, indicating that postMes- 
sage has been used to get the code; and client-secret , the secret shared 
by the RP and OP. 

8. OP —> RP: The OP checks the code, client-secret and redirect-uri and, 
if correct, responds to the RP with access-token and id-token, the 
latter of which is the same as the id-token sent in step El 

9. RP —> OP: The RP verifies the id-token. If it is valid, the RP now 
has evidence that the user has been authenticated. If necessary it can 
also make a web API call to retrieve the user attributes from the OP 
using the access-token as evidence of its right to do so. 

In Google’s implementation of Hybrid Server-side Flow, a code, an ac¬ 
cess- token and an id-token are always returned by Google to the RP’s 
JavaScript client running on the user’s browser. This means that these 
tokens are potentially revealed to the user agent and any applications which 
might be able to access the user agent. 

2.3.2 Client-side Flow 

The authorization request and response employed in the Client-side Flow are 
similar to those used in the Hybrid Server-side Flow. The only difference 
between the two flows is that in the Client-side Flow no code is submitted 
back to the RP. The Client-side Flow operates as follows, where steps 1-5 
are the same as steps 1-5 in section 12.3.11 

6. UA —>• RP: The UA executes the JavaScript inside the html document 
it received in the previous step. The JavaScript sends the authorization 
response using postMessage to the RP Client that is running on the 
UA and listening for the postMessage event. After receiving the 
authorization response, the RP Client extracts the access-token and 
id-token. It then verifies the id-token', if the id-token is valid, the RP 
now has evidence that the user has been authenticated. If necessary it 
can also make a web API call to retrieve the user attributes from the 
OP, using the access-token as evidence of its right to do so. 

7. UA —> U: The RP Client running on the UA updates the displayed 
web page based on the attributes it retrieved in the previous step. 
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2.3.3 Authorization Code Flow 


One advantage of this flow is that no tokens are made available to the user 
agent or to any malicious applications which might be able to access the 
user agent. This is advantageous since if either of the tokens are obtained 
by a malicious party they could be used to access sensitive user data and/or 
successfully masquerade as the user. The OP must authenticate the RP 
before it issues the pair of tokens, and hence use of the Authorization Code 
Flow requires that an RP shares a secret with the OP. The flow involves the 
OP returning an authorization code, typically a short-lived opaque string, 
to the RP, which uses it to obtain the id-token and access-token directly 
from the OP’s access-token endpoint, i.e. not via the UA. The main steps 
are as follows. 

1. U —» RP: The user clicks a login button on the RP website, as displayed 
by the UA, which causes the UA to send an HTTP or HTTPS request 
to the RP. 

2. RP —» UA —> OP: The RP generates an OpenID Connect authorization 
request and sends it to the OP via the UA. The authorization request 
includes client-id, a client identifier which the RP registered with the 
OP previously; response-type=code, indicating that the Authorization 
Code Flow is being used; redirect-uri, the URI to which the OP will 
redirect the UA after access has been granted; state, an opaque value 
used by the RP to maintain state between the request and the callback 
(step 0 below); and scope, the scope of the requested permission. 

3. OP —>• UA: If the user has already been authenticated by the OP then 
this step and the next are skipped. If not, the OP returns a login form 
which is used to collect user authentication information. 

4. U —>• UA —>• OP: The user completes the login form and grants per¬ 
mission for the RP to access the attributes stored by the OP. 

5. OP —> UA: After using the information provided in the login form to 
authenticate the user, the OP generates an authorization response and 
sends it back to the UA. The authorization response contains code, 
the authorization code generated by the OP; and state, the value sent 
in step [2j 

6. UA —> RP: The UA redirects the response received in Step 5 to the 

RP. 

7. RP —> OP: The RP produces an access-token request and sends it 
to the OP token endpoint directly (i.e. not via the UA). The request 
includes grant-type=code, indicating the RP wants to use the code to 


retrieve an access-token ; the code sent in stepO the redirect-uri: and 
client-secret, the secret shared by the RP and OP. 

8. OP —> RP: The OP checks the code, client-secret and redirect-uri and 
if all are correct responds to the RP with an access-token and id-token. 

9. RP —>• OP: The RP verifies the id-token. If it is valid, the RP now has 
evidence that the user has been authenticated. If necessary it can also 
make a call to the web API offered by the OP, using the access-token 
for authorisation, in order to retrieve the desired user attributes. 


3 Adversary Model 

In our assessment of the security of Google’s implementation of OpenID 
Connect, and of the implementations of specific RPs using the service, we 
consider two possible scenarios for the capabilities of an adversary. 

• A Web Attacker can share malicious links and/or post comments 
which contain malicious content (e.g. stylesheets or images) on a be¬ 
nign website; and/or exploit vulnerabilities in an RP website. The ma¬ 
licious content forged by a web attack might trigger the web browser 
to send HTTP/HTTPS requests to an RP and OP using either the 
GET or POST methods, or execute JavaScript scripts crafted by the 
attacker. For example, a web attacker could operate an RP website in 
order to try to collect access-tokens. 

• A Passive Network Attacker has the ability to intercept unen¬ 
crypted data sent between an RP and an end user browser (e.g. by 
monitoring an open Wi-Fi network). 

Conducting a security analysis of commercially deployed OpenID Con¬ 
nect SSO systems requires a number of challenges to be addressed. These 
include lack of access to detailed specifications for the SSO systems, undoc¬ 
umented RP and OP source code, and the complexity of APIs and/or SDK 
libraries in deployed SSO systems. The methodology we used is similar to 
that employed by Wang et al. [33J and Sun and Beznosov SB, i.e. we anal¬ 
ysed the browser relayed messages (BRMs). We treated the RPs and IdPs 
as black boxes, and analysed the BRMs produced during authorization to 
look for possible exploit points. Since we used a black-box approach, there 
may very well be vulnerabilities, implementation flaws and attack vectors 
which our study did not uncover. 
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4 A Security Study 


To evaluate the security of OpenID Connect, we used Fiddlei@ to capture 
BRMs sent between RPs and the OP; we also developed a Python program 
to parse the BRMs to simplify analysis and to avoid mistakes resulting from 
manual inspections. All the experiments were performed using accounts set 
up specially for the purpose; i.e. at no time was any user’s account accessed 
without permission. Of the 103 RPs supporting Google OpenID Connect 
that we examined, we found that 69 (67%) adopt the Authorization Code 
Flow , 33 (32%) use the Hybrid Server-side Flow, and just 1 adopted the 
Client-side Flow. 

4.1 Studying the security of the Hybrid Server-side Flow 

As described in section [2. 3. 11 Google’s OpenID Connect API uses postMes- 
sage to deliver the authorization response from the OP to an RP. When the 
RP Client running on the user’s browser receives the authorization response 
from the OP, it extracts the code from the authorization response and then 
submits the code back to the RP’s OpenID Connect sign-in endpoint. 

4.1.1 Authentication by Google ID 

As stated above, the RP’s JavaScript client running on the UA submits the 
code it receives from the Google OP back to the RP’s Google sign-in endpoint 
(see step 6 in section 12.3.11) . The code plays a critical role in guaranteeing 
the user identity to the RP, in that the RP is meant to use it to retrieve the 
access-token and id-token from the Google OP. However, we observed that 
18% of the RPs using the Hybrid Server-side Flow (i.e. 6 of the 33) submit 
the user’s Google ID to the RP’s Google sign-in endpoint; of these six RPs, 
two simply submit the user’s Google ID without appending a code, and one 
submits the user’s Google ID with an access-token. This led us to suspect 
that such RPs might be basing their verification of user identity solely on 
the Google ID, and not using the code as it is intended to be used. If this 
were to be the case, then a web attacker which knows a user’s Google ID 
could use it to log in to the user’s RP account. We tested this, and found 
that as many as 9% of the RPs using the Hybrid Server-side Flow (i.e. 3 of 
the 33) have this vulnerability. 

It would appear that learning the Google ID for a victim user 
can be relatively simple, as a user’s Google-I- post URL reveals the 
user’s Google ID. An attacker can use the Google-I- search for peo¬ 
ple function to find a victim user to attack, and can then visit 
the chosen victim user’s Google-|- page to learn the ID. For exam¬ 
ple, https://plus.google.eom/u/0/115722834054889887046/posts is 

^ttp://www.telerik.com/fiddler 


10 








the Google-)- post URL for a Gmail account, for which the ID is 
115722834054889887046. 

We reported our findings to the three affected websites, and recommen¬ 
dations were also provided to enable the RP developers to fix the problem 
(see also m- 

4.1.2 Using the Wrong Token 

An access-token is a bearer token; this means that any party in possession 
of an access-token can use it to get access to the associated user attributes 
stored by Google. This is the intended use of an access-token ; by contrast, 
the id-token is designed for use for providing assurances about user authen¬ 
tication. However, in practice, some RPs use an access-token as a means 
of obtaining assurances about user authentication without verifying it (i.e. 
making a web API call to the OP token information endpoint 0 )- In such 
a case, any party (e.g. another RP) that has obtained a user’s access-token 
can impersonate that user to the RP simply by submitting it. This is a 
particular threat in the case of a malicious RP, which can routinely obtain 
access-tokens from the Google OP. In other words, any RP using Google 
OpenID Connect has the ability to log in as a victim user to any RPs which 
use an access-token to authenticate the user without verifying it. Unfortu¬ 
nately, we found that 58% of RPs using the Hybrid Server-side Flow (i.e. 
19 out of 33) submit an access-token back to their Google sign-in endpoint 
(see step 6 in section 12.3.11) and 45% (i.e. 15 out of these 19) use the ac- 
cess-token to authenticate the user; of these 15 RPs, only two RPs verify 
the access-token before using it to retrieve user attributes. As a result, 
39% of the RPs (i.e. 13 out of 33) that we examined are vulnerable to this 
impersonation attack. 

We tested the above attack using Burp SuitcH by submitting an ac¬ 
cess- token obtained from the 9GAGo website to the target RP’s Google 
sign-in endpoint. If the attack succeeds, we are able to log in to the target 
RP as the victim user. As noted above, as many as 39% of the RPs using 
the Hybrid Server-side Flow are vulnerable to this attack. Some of the vul¬ 
nerable RPs (i.e. 3 out of 13) require additional evidence of the user to be 
submitted with the access-token, in the form of the Google ID or the user’s 
email address. However, an attacker that has an access-token can very eas¬ 
ily use it to obtain the user’s Google ID and/or email address from Google, 
and so such additional steps do not prevent the impersonation attack. 

^http://portswigger.net/burp/ 

1 http://9gag.com 
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4.1.3 Intercepting an access-token 

As stated above, 58% of RPs using the Hybrid Server-side Flow require the 
submission of an access-token back to their Google sign-in endpoint (see 
step 6 in section 12.3.111 . If the RP Client running on the UA sends an 
access-token back to its Google sign-in endpoint without SSL protection, a 
passive network attacker is able to intercept it (see section [3J) . According 
to the OAuth 2.0 specification m, an access-token should never be sent 
unencrypted between the user browser and the RP. However, we found that 
12% of RPs using the Hybrid Server-side Flow (i.e. 4 out of 33) send the 
access-token unprotected. A sniffer written in Python was implemented to 
test this. 

We also observed that one additional site, namely TheFreeDictionarjjf] 
does use SSL to protect the transfer of the code to its Google sign-in end¬ 
point. However, the access-token is subsequently stored in a cookie, and 
when the cookie is sent from the browser back to TheFreeDictionary the 
link is not SSL-protected. That is, the access-token is observable by a pas¬ 
sive eavesdropper. 

4.1.4 Privacy Issues 

When a user chooses to use OpenID Connect to log in to an RP website, 
the user attributes (e.g. email address, name) that the RP retrieves from the 
OP should never be revealed to parties other than the RP. SSL connections 
should be established to protect user information transmitted between the 
browser and the RP or OP. 

However, as explored in greater detail below, user information leakage 
might happen if: 

• the RP Client running on the user’s browser sends user information, 
the id-token or the access-token back to its Google sign-in endpoint 
without SSL protection (see step 6 in section I2.3.ip : 

• the RP Google sign-in endpoint sends the user information directly to 
the user’s browser without SSL protection; or 

• the RP uses SSL to protect the link to the Google sign-in endpoint, 
but changes to http when it sends the user’s information back to the 
user’s browser. 

As described in Section 14.1.31 a passive eavesdropper can intercept the 
access-token for 12% of the RPs that use the Hybrid Server-side Flow (i.e. 
4 out of 33), and can then use it to retrieve potentially sensitive user in¬ 
formation, notably including the Google ID and email address. As stated 
in section m the id-token is a JSON web token, in which the user email 

J http://www.thefreedictionary.com 
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address and Google ID are encoded in cleartext using Base64; as a result 
anyone obtaining the token can immediately obtain the information within 
it. One of the four RPs referred to above sends an id-token in addition 
to the access-token to its Google sign-in endpoint, and thus a passive web 
attacker can retrieve the user information it contains without requesting it 
from Google using the access-token. We also found that one RP did not 
enable SSL to protect its Google sign-in endpoint and returned user infor¬ 
mation directly to the user browser. Another RP sends user information 
back to its Google sign-in endpoint without SSL protection. Yet another 
RP uses SSL to protect the link to the Google sign-in endpoint, but changes 
to HTTP when it sends the user information back to the user browser. As a 
result, user privacy cannot be guaranteed for 21% of the RPs we examined 
(i.e. 7 out of 33). As noted above, a sniffer in Python was implemented to 
demonstrate the feasibility of the attack. 

4.1.5 Session Swapping 

As discussed earlier, the RP Client running on the UA sends the user’s 
OpenID tokens (i.e. one or more of a code, an access-token, an id_token, 
and the user’s Google ID) back to its Google sign-in endpoint (see step 6 in 
section [2.3. Hi . The OpenID Specification [37] recommends that a state value 
should be appended when the RP Client sends the tokens back to its Google 
sign-in endpoint, and that this state value should be bound to the browser 
session. If the RP Client fails to send the state value, an attacker can execute 
a session swapping attack mmm by performing the following steps. 

1. The attacker first logs in to the RP website using his or her own ac¬ 
count (see step 4 in section 12.3.111 , and intercepts the tokens generated 
by Google (see step 5 in section 12.3. ID . 

2. The attacker constructs a request to the RP’s Google sign-in endpoint 
including the attacker’s own tokens. 

3. The attacker inserts the request in an HTML document (e.g. in the 
src attribute of a img or iframe tag) which is made publicly available 
via an HTTP server. 

4. The victim user is now, by some means, induced to visit the website of¬ 
fering the attacker’s web page. The HTML can be constructed in such 
a way (described in detail below) that the victim’s UA will automati¬ 
cally use the GET or POST method to send the attacker-constructed 
request to the RP; as a result the user session on the RP website will 
be bound to the attacker’s account. 

We observed that 42% of the RP Clients using the Hybrid Server-side 
Flow (i.e. 14 out of 33) use the POST method to submit the tokens back 
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to the RP’s server without an accompanying state value. Use of a static 
img or iframe tag to perform an attack of the above type does not work 
against these RPs, as the browser will automatically use the GET method to 
retrieve the img and iframe data. Thus, in order to use the POST method 
to submit those tokens, we created a special HTML page to conduct our 
session-swapping attack. We used JavaScript to create an iframe with a 
unique name in the browser. We then constructed a form inside the iframe 
whose action points to the RP’s Google sign-in endpoint. We then put the 
attacker’s tokens into the form input and configured the HTML to submit 
the form whenever the HTML document is loaded into a browser. 

To deploy the attack, the constructed HTML page is made available 
via a publicly available web server. If a victim user visits this page, the 
JavaScript inside the HTML automatically submits the attacker’s tokens to 
the RP using the POST method; as a result the victim user’s session on 
the RP is bound to the attacker’s, i.e. a session-swapping attack has been 
performed. An attacker could use such an attack to collect sensitive user 
information, e.g. if the victim user updates his credit card information on 
the RP website, the credit card information will be written to the attacker’s 
account. 

Unfortunately, we found that 73% of RPs which adopt the Hybrid Server- 
side Flow (i.e. 24 out of 33) are vulnerable to this attack. Of these 24 
RPs, eight (i.e. 24% of this category) submit a code to their Google sign-in 
endpoint; as the code is a one-time value, the attacker must update it within 
the attack HTML every time the page is retrieved by a victim user. For the 
other 48% of vulnerable RPs (i.e. 16 out of 33), an access-token or the user’s 
Google ID is submitted back to the Google sign-iu endpoint, in which case 
the attacker does not need to update the attack page HTML as frequently. 

4.2 Studying the security of the Authorization Code Flow 

We start by observing that Google’s OAuth 2.0 Authorization Code Flow 
implementation [12] has similar steps to those given in 12.3.31 The token 
endpoint provided as part of Google’s implementation of OAuth 2.0 (as 
checked on April 22, 2015) returns an id-token to the RP. That is, with¬ 
out knowing details of the RP’s internal operation, we cannot distinguish 
whether an RP is using OpenID Connect or OAuth 2.0. In this paper we 
therefore cover all cases where Google returns a code to the RP’s Google 
sign-in endpoint under our discussion of the OpenID Connect Authorization 
Code Flow, even though some of the RPs concerned may actually be using 
OAuth 2.0. However, this makes no difference to our security analysis. 

Around 67% of the RPs we examined (i.e. 69 out of 103) use the Au¬ 
thorization Code Flow. Unlike the Hybrid Server-side Flow, Google’s im¬ 
plementation of Authorization Code Flow uses HTTP status code redirect 
techniques (i.e. using code 302) to deliver the authorization response to the 
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RP’s Google sign-in endpoint. 


4.2.1 Intercepting an access-token 

In the Authorization Code Flow, a code is returned by Google to the RP’s 
Google sign-in endpoint (see step 6 in section f2.3.3|) . No tokens are trans¬ 
mitted during the authorization procedure. After the RP receives the code, 
it can use it to retrieve an access-token from Google (steps 7/8 in 12.3.311 ; it 
can then use the access-token to retrieve user attributes from Google (step 
9 in 12.3.311 . The RP then logs the user in to its website. 

If an RP does not use SSL to protect communications with its Google 
sign-in endpoint, a passive web attacker may be able to intercept the code. 
A passive web attacker cannot use the code to retrieve an access-token from 
Google, as it will not know the RP’s client-secret (shared by the RP and 
Google). However, we observed that, of the RPs using the Authorization 
Code Flow, 6% of their Google sign-in endpoints (i.e. 4 out of 69) return 
an access-token to the user’s browser instead of binding the user to the 
RP’s session. As these RPs do not use SSL to protect the transfer of the 
access-token, a passive web attacker is able to obtain the user’s access-token 
returned from the RP’s Google sign-in endpoint. 

4.2.2 Stealing an access-token via Cross-site Scripting 

Google’s “automatic authorization granting” feature m generates an au¬ 
thorization response automatically if the user has maintained a session with 
Google and has previously granted permission for the RP concerned. Us¬ 
ing this feature, an attacker might be able to steal a user access-token by 
exploiting an XSS vulnerability in the RP or the browser. 

To test the feasibility of such an attack, an exploit written in JavaScript 
was implemented. The exploit takes advantage of a recently revealed vul¬ 
nerability in Android’s built-in browser P3j which allows an attacker to 
conduct a universal XSS attack [301 El sa US]- The exploit uses a browser 
window.open event to send a forged authorization request to Google’s au¬ 
thorization server, within which response-type=code (see step 2 in 12.3.311 is 
changed to response-type=code token id-token. If the user is logged in to 
his or her Google account and has previously granted permission for this 
RP, Google automatically generates an authorization response without the 
involvement of the user; this response is appended as a URI fragment (#) to 
the redirect URI (see step 5 in section 12.3.31) and is sent back to the RP (see 
step 6 in section 12. 3. 3D . As the RP Google sign-in endpoint does not expect 
an URI fragment, a predefined error page will be generated by the RP (e.g. a 
‘404 not found’ or ‘Failed connection’ error). The exploiting JavaScript can 
now extract the authorization response from the URL of the error page and 
send it to its opener window, where the window.open event is triggered. 
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The opener window then sends the access-token to the attacker’s server. 

Unfortunately, our results show that all the RPs that adopt the Autho¬ 
rization Code Flow are vulnerable to this attack. The vulnerability affects 
all Android versions up to 4.4, which as of April 6, 2015 still accounted for 
53.2% of Android device^]. 

4.2.3 Privacy Issues 

Unlike the Hybrid Server-side Flow , only a code is submitted back to the 
RP’s Google sign-in endpoint (see step 6 in section 12.3.31 ). No user informa¬ 
tion (e.g. a Google ID or an id-token ) is transmitted during the authorization 
procedure. However, user information leakage might nevertheless occur if 
the RP Google sign-in endpoint sends the user information directly to the 
user’s browser without SSL protection. 

Our study revealed that 16% of RPs using the Authorization Code Flow 
(i.e. 11 out of 69) return user information to the browser directly without 
SSL protection. Thus a passive web attacker is able to intercept potentially 
sensitive user information, e.g. if the user is using an open Wi-Fi network 
(see section ED. 

4.2.4 Session Swapping 

If an RP using the Authorization Code Flow does not enable anti-CSRF 
measures (e.g. by appending a state value bound to the browser session 
to the tokens) to protect its Google sign-in endpoint, a web attacker can 
launch a session swapping attack, precisely as described in 14.1.51 for the 
Hybrid Server-side Flow. 

Unlike the session swapping attack in 14.1.51 in the Authorization Code 
Flow only the GET method is used to submit the code back to the RP’s 
Google sign-in endpoint. This means that the attacker can simply insert 
the forged request in the src attribute of a img or iframe tag of an HTML 
document. When the victim user visits the malicious HTML, the browser 
will automatically send the request to the RP’s Google sign-in endpoint 
using the GET method. 

We found that 35% of the RPs using the Authorization Code Flow (i.e. 

24 out of 69) are vulnerable to this attack. However, as the code is a one 
time value, the attacker has to update it every time the attack page is 
visited by a victim user. As a result such an attack is not as harmful 
as the session swapping attack in the Hybrid Server-side Flow, where an 
access-token which can be used multiple times is submitted back to the 
RP’s Google sign-in endpoint. 

"https://developer.android.com/about/dashboards/index.html?utm_source=suzunone 
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4.2.5 Forcing a Login Using a CSRF attack 

A CSRF login attack operates in the context of an ongoing interaction be¬ 
tween a target web browser (running on behalf of a target user) and a target 
RP. In such an attack, a malicious website somehow causes the target user’s 
browser to initiate an OpenID Connect authorization request to the OP. Be¬ 
cause of Google’s “automatic authorization granting” feature, receiving such 
a request can cause the Google OP to generate an authorization response 
which is delivered to the RP without the involvement of the user. If the 
target user is currently logged in to Google, the browser will send cookies 
containing the target user’s Google OP-generated tokens, along with the 
attacker-supplied authorization request, to the OP. The OP will process 
the malicious authorization request as if it was initiated by the target user, 
and will generate an authorization response and send it to the RP. The 
target browser could be made to send the spurious request in various ways; 
for example, a malicious site visited by the browser could use the HTML 
img tag’s src attribute to specify the URL of a malicious request, causing 
the browser to silently use a GET method to send the request. 

Our experiments have shown that 35% of the RPs which adopt the Au¬ 
thorization Code Flow (i.e. 24 out of 69) are vulnerable to such an attack. 
One consequence of this attack is that an attacker can cause a victim user 
to log in to the RP, as long as the user has previously logged in to Google. 
This could damage the user experience of the RP website, as the victim user 
might dislike such a potentially annoying “automatic login” feature. 

5 Discussion 

OpenID Connect builds on top of the current web infrastructure, in which 
web application vulnerabilities (e.g. cross-site request forgeries, cross-site 
scripting) are common and have been widely exploited [2]. The existence of 
these vulnerabilities exacerbates the threat posed by some of the implemen¬ 
tation issues we have identified. 

Most of the vulnerabilities described in section [5] are caused by a com¬ 
bination of certain characteristics of the Google service and RP design de¬ 
cisions that appear to value simplicity over security. We next consider in 
greater detail how and why the various classes of vulnerability that we have 
identified have arisen. 

5.1 Customising the Hybrid-Server-side Flow 

According to the OpenID Connect specification m, a code must be returned 
by the OP to the RP’s Google sign-in endpoint (see step 6 in section 12.3.11) . 
However, as described in section El many RPs using the Hybrid Server- 
side Flow do not properly follow the specification, and in particular some 
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RP Clients submit an access-token , an id-token and/or a Google ID back 
to their Google sign-in endpoints. It appears that the OpenID Connect 
Specification only acts as a loose guideline for these RPs. 

Meanwhile, the authorization request generated in the Hybrid Server- 
side Flow by RPs which use Google’s OpenID Connect API will always 
include response-type=code token id-token ; therefore the authorization re¬ 
sponse which is sent to the RP Client contains a code , access-token and 
id-token. Unlike the Authorization Code Flow , where only a code is re¬ 
turned to the RP’s Google sign-in endpoint (see step 6 in section 12. 3.3 D and 
no RP Client exists, this gives the RP the ability to customise their Hybrid 
Server-side Flow. In fact our experiments have shown that as many as 70% 
of RPs (i.e. 23 out of 33) customise their Hybrid Server-side Flow. These 
customisations potentially improve the performance of the OpenID Connect 
system at the RP as well as enhancing the user experience, but they also risk 
introducing new vulnerabilities into the system, e.g. allowing an attacker to 
log in to the RP as any victim user (see section 14.1.111 and to impersonate 
the victim user using an access-token generated for another RP (see section 
14.1.21) . Moreover, as the code , access-token and id-token are returned by 
Google inside a HTML document, these values are also revealed to the user 
agent and hence to any applications (e.g. browser plug-ins), which might be 
able to access the user agent. If the plug-in or user agent has vulnerabilities 
which could allow an attacker to access these values, the attacker can steal 
the user’s access-token', for example a malicious plug-in which has the right 
to read the content of HTML pages could obtain the access-token. 

5.2 Confusion over use of the state value in the Hybrid- 
Server-side Flow 

When RP developers construct the authorization request using the Google 
OpenID Connect API, they only need to specify the RP client-id and per¬ 
mission scope in their code, as the other values in the authorization request 
are handled by the API. These other values include the state, which is used 
to bind the authorization response to the authorization request, thereby 
preventing CSRF attacks mmmm- This simplifies the job of the RP 
developers and makes support for Google’s OpenID Connect easier to im¬ 
plement, but at the cost of increasing the attack surface and opening the 
protocol to new vulnerabilities. In order to understand how the API deals 
with the state value, we implemented an RP using the Google OpenID Con¬ 
nect API. Surprisingly, we found that the state value extracted by the RP 
Client is actually a null value; this means that Google itself fails to deliver 
the state value to the RP Client, and hence the state value cannot be used 
to mitigate the threat of a CSRF attack. We also observed that one of the 
RPs using the Authorization Code Flow sends a null state value back to its 
Google sign-in endpoint. 
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As the state value generated by the Google OpenID Connect API is 
not bound to the RP’s session and cannot be extracted by the RP Client, 
another state value which is bound to the session needs to be implemented to 
protect the RP’s Google sign-in endpoint against a CSRF attack. However, 
73% of RPs using the Hybrid Server-side Flow fail to take this step. As a 
result they are all vulnerable to the session swapping attack described in 
section 14.1.51 

Google does recommend RPs to use a state value to protect their Google 
sign-in endpoint. However, examination of the Google OpenID Connect 
sample code [3] reveals that Google has not included a state value in its 
example of an RP Client-generated AJAX request, which is used to send 
data back to the RP [10] . The lack of a state parameter in the sample code 
and the complexity of implementing anti-CSRF measures helps to explain 
why 73% of the RPs using the Hybrid Server-side Flow are vulnerable to 
this attack. 

5.3 Automatic Authorization Granting 

The “automatic authorization granting” feature of Google’s implementation 
of OpenID Connect significantly enhances the user experience and system 
performance. Without this feature, the user would have to click the “OK” 
button in a popup window whenever he or she wished to log in to an RP, 
in order to grant authorization. However, this feature can also be harmful, 
since its use may allow an attacker to steal an access-token (see section l4.2.2D 
and force a user log in to the RP (see section 14.2.51) . 

We also observed that in the Hybrid Server-side Flow , iframes are used 
to manage the session [5] between the RP Client and the OP. Suppose that 
a user, who has previously both granted permission for the RP and logged 
in to his or her Google account, visits the RP login page which contains 
an iframe pointing to the authorization request. Because of the “automatic 
authorization granting” feature, the browser can use the GET method to 
retrieve the authorization response from Google without the involvement 
of the user. The user agent and any applications (e.g. plug-ins) which can 
access the user agent are able to extract the authorization response, which 
might expose the Hybrid Server-side Flow to new attacks. 

6 Recommendations 

OpenID Connect has been deployed by many RPs and OPs, and it appears 
that increasing numbers of RPs supporting the Google service will imple¬ 
ment OpenID Connect for SSO now that Google has shut down its OpenID 
service. However, our study has revealed serious vulnerabilities in existing 
systems, and there is a significant danger that these vulnerabilities will be 
replicated in future systems. 
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Below we make a number of recommendations, directed at both RPs 
and OPs, designed to address the vulnerabilities we have identified. These 
recommendations primarily apply to RPs using the Google service and to the 
Google OP itself, but some may have broader applicability. There are two 
reasons for making these recommendations, namely both to try to address 
the problems that exist in current systems, and to help ensure that future 
systems are built in a more robust way. 

6.1 Recommendations for RPs 

When using the OpenID Connect system, especially in the case of the Hybrid 
Server-side Flow, the RP’s developers are responsible for designing the RP 
Client action upon receiving an authorization response from the Google 
OP. As a result the security of the OpenID Connect system for the RP 
largely depends on the security expertise of the RP developers. We have the 
following recommendations for RPs. 

• Do not customise the Hybrid Server-side Flow: One of the rea¬ 
sons OpenID Connect is vulnerable to the attacks described in sections 
I4.1.1l and l4.1.2l is that the RPs customise the Hybrid Server-side Flow. 
In particular, instead of submitting a code back to its Google sign-in 
endpoint, the RP Client running the UA submits an access-token or 
Google ID, which is used by the RP to authenticate the user. Such 
a customised Hybrid Server-side Flow might improve the user experi¬ 
ence and the efficiency of the RP website, but at the cost of exposing 
the system to new attacks. RPs must implement the OpenID Connect 
Hybrid Server-side Flow strictly conforming to the OpenID Connect 
Specification. 

• Deploy countermeasures against CSRF attacks: One reason the 
OpenID Connect systems we have investigated are vulnerable to CSRF 
and session swapping attacks is that the RPs have not implemented 
any of the well-known countermeasures to such attacks. In order to 
prevent CSRF attacks, Google recommends RPs to include the state 
parameter in the OpenID Connect authorization request and response, 
and RPs should follow this recommendation. 

• Do not use a constant or predictable state value: Some RPs in¬ 
clude a fixed state value in the OpenID Connect authorization request. 
If the state value is fixed, it cannot be uniquely bound to the browser 
session, thereby allowing an attacker to successfully forge a response, 
since the RP cannot distinguish between a legitimate response pro¬ 
duced by a valid user and a forged response produced by an attacker. 
Hence, in such a case, the inclusion of the state value does not protect 
against CSRF attacks. Thus RPs must generate a non-guessable state 
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value which should be bound to the browser session so that the state 
value can used to verify the validity of the response. 

6.2 Recommendations for OPs 

In an OpenID Connect SSO system, the OP designs the process and provides 
the API for RPs. An RP wishing to support a particular OP must therefore 
comply with the requirements of that OP, and so the OPs play a critical 
role in the system. We have the following recommendations for OPs (and 
in particular for Google). 

• Remove the token from the authorization request in the Hy¬ 
brid Server Flow: In the Hybrid Server-side Flow, the token in the 
authorization request causes Google to return an access-token to the 
RP Client. This allows RP Clients to submit an access-token back 
to their Google sign-in endpoints, as was the case for 58% of RPs us¬ 
ing the Hybrid Server-side Flow that we investigated. This practice 
gives rise to a range of possible impersonation attacks. Sending the 
access-token also creates further risks, since if the RP does not enable 
SSL to protect its Google sign-in endpoint, a passive network attacker 
could steal it. This would not only enable a malicious RP to imperson¬ 
ate a user to those RPs which submit an access-token to the Google 
sign-in endpoint, but also allow the possibility of other misuses of this 
token, e.g. to compromise sensitive user data. 

• Add a state value to the sample code: OPs typically provide 
sample code to help RP developers make their website interact ap¬ 
propriately with the OP. As we discovered, Google does not include 
a state value in its sample code for the Hybrid Server-side Flow. It 
seems reasonable to speculate that this is the main reason why 73% of 
the RP-OP interactions we have analysed (see section 14. 1.511 are vul¬ 
nerable to session swapping attacks. However, for cases where a state 
value is included in Google’s sample code, this number fell to 35% (see 
section 14.2.4)1 . 

• Allow the RP to specify the state value in the Hybrid Server 
Flow: The state value in the authorization request of the Hybrid 
Server-side Flow is automatically handled by the Google OpenID Con¬ 
nect API. However, the RP Client cannot extract the state as it is 
a null value. As the state value is not bound to the browser session, 
it does not protect the RP against CSRF attacks. It would probably 
be better to let the RP handle the state value rather than the Google 
API handle it. In addition, Google should check the source code of its 
postmessage.js script to ensure that the state value can be extracted 
by the RP Client. 
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6.3 Notifying affected parties 

We reported the issues described in section H.l. II to the three affected parties 
in February and also provided advice to help them fix the problem. As 
of 30 July 2015, one of the three has fixed the problem, one has ignored 
our warning, and the third terminated support for the Google SSO service. 
On April 17th 2015 we also notified Google of all the issues described in 
this paper. Google acknowledged the problem described in section 15.21 and 
notified their OpenID Connect group. 

7 Related Work 

OAuth 2.0, as the predecessor of OpenID Connect, has been analysed using 
formal methods. Pai et al. [35] confirmed a security issue described in the 
OAuth 2.0 Thread Model [32] using the Alloy Framework [26]. Chari et al. 
analysed OAuth 2.0 in the Universal Composability Security framework m 
and showed that OAuth 2.0 is secure if all the communications links are 
SSL-protected. Frostig and Slack [39] discovered a cross site request forgery 
attack in the Implicit Grant flow of OAuth 2.0, using the Murphi framework 
|2l ]. Bansal et al. m analysed the security of OAuth 2.0 using the WebSpi 
[16 ] and ProVerif models m- However, all this work is based on abstract 
models of OAuth 2.0, and so delicate implementation details are ignored. 

Meanwhile, a range of work exploring the security properties of real- 
world implementations of OAuth 2.0 has also been conducted. Wang et 
al. [43] examined a number of deployed SSO systems, focussing on a logic 
flaw present in many such systems, including OpenID. In parallel, Sun and 
Beznosov m also studied deployed systems of OAuth 2.0 providing services 
in English. Li and Mitchell m examined the security of deployed OAuth 
2.0 systems providing services in Chinese. In parallel, Zhou and Evans m 
conducted a large scale study of the security of Facebook’s OAuth 2.0 imple¬ 
mentation. Chen et al. 22] . and Shehab and Mohsen [351] have looked at the 
security of the implementation of OAuth 2.0 on mobile platforms. However, 
despite all the work on OAuth, very little research has been conducted on 
the security of OpenID Connect systems. 

8 Concluding Remarks 

In this paper, we have reported on the first field study of the security prop¬ 
erties of Google’s implementation of OpenID Connect. We examined the se¬ 
curity of all 103 of the RPs that implement support for the Google OpenID 
Connect service from the GTMetrix list of the Top 1000 Sites. The method¬ 
ology we used to discover vulnerabilities is similar to that used by Wang 
et al. [13] and Sun and Beznosov m , i-e. we analysed the HTTP mes- 
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sages transmitted between the RP and OP via the browser; however, our 
approach was different in two key respects. First, we added a further class 
of adversary to the threat model, in which a malicious RP tries to collect 
user access-tokens and then use them to impersonate the user to other RPs. 
Second, we focussed our study on OpenID Connect rather than OAuth 2.0 
and other generic SSO systems. This has allowed us to to identify gaps 
between the implementation and specification of OpenID Connect, discover 
a number of vulnerabilities which allow an attack to log in to the RP as a 
victim user, and propose practical and useful improvements which can be 
adopted by all OpenID Connect RPs and OPs. 
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